home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1088 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.6 KB
  1. Subject: Gem List
  2. Subject:  Re: A better objc_edit()
  3. Date: Wed, 27 Jul 94 20:59 EST
  4. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  5. To: ems <gem-list@world.std.com>
  6. Subject: Gem List
  7. Message-Id: <81940728015918/0006795560PK1EM@mcimail.com>
  8. Precedence: bulk
  9.  
  10. Subject:  Re: A better objc_edit()
  11.  
  12. Someone (Who the HELL is this?!):
  13. ---------------------------------
  14. > Bravo, Bravo!  Let's get down to some useful business.
  15.  
  16. That's what I've been trying to do, but somehow, everyone got sidetracked.
  17.  
  18. > What I need to know is how to find out the owner of a window with normal
  19. > TOS.
  20.  
  21. With normal TOS, there is no way to find out which window belongs to what.
  22. You would have to keep a running tab in memory of which windows are open
  23. that belong to you.  To do so:
  24.  
  25. typedef struct window_owners
  26. {
  27.     int handle;
  28.     int owner;
  29. } WOWNERS;
  30.  
  31. WOWNERS owned_winds[20]; /* Some TOS versions allow more than 7 winds */
  32.  
  33. GLOBAL int WOpenWindow( ... )
  34. {
  35.     /* Open your window */
  36.     owned_winds[window_handle].handle = window_handle;
  37.     owned_winds[window_handle].owner  = Application_ID;
  38. }
  39.  
  40. GLOBAL int WCloseWindow( ... )
  41. {
  42.     /* Close and delete your window if linked to a list */
  43.     owned_winds[window_handle].handle = 0;
  44.     owned_winds[window_handle].owner  = 0;
  45. }
  46.  
  47. GLOBAL WGetOwner(int handle)
  48. {
  49.     if ((handle != 0) && (owned_winds[handle].owner == Application_ID))
  50.         return TRUE;
  51.     else
  52.         return FALSE;
  53. }
  54.  
  55. Hope that helps a bit.  This is the same type of code I have put into XAES,
  56. and it helps, especially when you work with your program as an accessory,
  57. or if you run it with Geneva or MultiTOS.  Window ownership routines are a
  58. very good idea, and they should be standard.  They are *VERY* easy to
  59. implement.
  60.  
  61. Also, keep in mind that if you make your own wind_get and wind_set, then you
  62. can trap WF_OWNER [value = 20] and return the owner.  :-)
  63.  
  64. > It's not busy-waiting at all... event_multi will pass mouse events to my 
  65. > application when MCTRL is set, otherwise, the OS just sits there.
  66.  
  67. I don't quite think you understand how event_multi handles the mouse.  If
  68. you move the mouse and you don't have a timer set, you will never get a
  69. mouse movement message, as they are always being returned.  You could also
  70. wait for mouse button 0 and mouse state 0, but it's the same effect.
  71.  
  72. > And besides, who cares about busy-waiting when you're not multitasking?
  73.  
  74. DON'T get us started in this discussion again.
  75.  
  76. > You can't make a distinction with normal TOS.  You only get WF_TOPPED 
  77. > messages.  What I'm trying to do is simulate WF_BEVENT when I don't have 
  78. > a multitasking OS.
  79.  
  80. But I'm telling you, IT'S EASY!  Just *try* the methods I've discussed.  If
  81. you can't figure it out after that, then there's not much that I can help
  82. you with.  Quit TALKING and actually *try* doing some of the things I've
  83. mentioned.  You will not regret it.
  84.  
  85. There doesn't seem to be WF_OWNER under normal TOS, and getting a 
  86. window's handle doesn't give me the application's name, does it?
  87.  
  88. > I just want example code I can use to make sure that mine doesn't miss 
  89. > something.  I want a form_button replacement that will work on a 
  90. > background window, using the rectangle list of the window.
  91.  
  92. To make sure it doesn't miss anything, make sure that you use:
  93.  
  94. object_state |= SELECTED;    /* Turn on selected bit */
  95. object_state &= ~SELECTED;    /* Turn off selected bit */
  96.  
  97. If you use those methods, or use "bitchg" routines (available on a.a.u.e) you
  98. can do it easily.
  99.  
  100. > Oh, I don't even need that.  If some exotic key were to be pressed, I 
  101. > could just pass something DIFFERENT to form_keybd.
  102.  
  103. Or you could just bypass form_keybd altogether.
  104.  
  105. > For example, when you click the first time on an edit field, it acts 
  106. > normal, but the second time, it will move the insertion point to where 
  107. > you clicked by repeatedly sending arrow keys to form_keybd.
  108.  
  109. That doesn't really have anything to do with form_keybd.  That has to do with
  110. the repositioning of the cursor by using objc_edit (on) and objc_edit (off)
  111. to reposition the object, keeping in mind that you have to set a NULL
  112. character in front of the character where you wish to position the cursor.
  113. Once you do that, turn the cursor on.  You will have the cursor repositioned.
  114. VOILA!  :-)
  115.  
  116. ]> Are the icons on the desktop part of a desktop form?  If so, how do
  117. ]> programs get away with replacing the the background without removing the
  118. ]> desktop's object tree?
  119.  
  120. > You didn't answer my question.
  121.  
  122. Yes, ICONS are the part of the desktop form.  It all depends on the form that
  123. you put on the desktop with WF_NEWDESK.  What do you mean by the second
  124. question?  When you move a window, it automatically redraws the desktop
  125. form, regardless of what's on it.
  126.  
  127. -- Ken Hollis (Bitgate Software)
  128.  
  129.